Many modern computers contain a time stamp counter, or TSC, which is a simple counter, incremented at each CPU clock cycle. Thus, the TSC is tied to the CPU frequency of the particular computer on which it is running.
In a virtual machine (VM) environment, the TSC for each VM may be simulated in several ways. Instructions which read the counter may be trapped, allowing a hypervisor to modify the apparently observed counter value; or the counter may be passed through directly to a guest operating system (OS). The latter approach avoids the hypervisor trap, which can present a performance problem when there is frequent use of the TSC. However, presenting the TSC directly to the guest VM is problematic because the TSCs of different processors on a machine may not be synchronized. Furthermore, it is problematic because the guest may attempt to reset the apparent TSC counter, but the hypervisor cannot allow such a reset of the underlying TSC because it would interfere with the operation of the hypervisor itself. In addition, setting the TSC to an arbitrary value may not be possible on all hardware platforms.
Some newer hardware virtualization technologies allow an offset to be added to the TSC when running a virtual machine. This allows the hypervisor to modify the apparent guest TSC without any performance penalty, while allowing for simulation of a reset and also preserving the desirable feature of presenting a zero TSC counter to a guest VM upon boot.
Unfortunately, none of these above-described techniques can accommodate for a change in the TSC frequency of a processor. The TSC frequency of a processor may change in one of two ways. First, some CPUs support what is known as frequency scaling: the processor frequency is increased or decreased according to performance requirements. Second, the underlying TSC rate may change upon migration to a different computer, which is a common occurrence for VMs in particular. As a result of a processor's TSC frequency change, time as measured by the TSC moves either faster or slower, depending on whether the TSC rate associated with the new processor speed is faster or slower, respectively, than the old processor speed.
The calculation of the TSC speed is typically done only once, during the boot process of the VM. Currently, there is no reliable standard for informing the VM of a change in speed so it may compensate for its virtual TSC. Further, even if there were such a standard, many guest OSs are not equipped to deal with such a change as they have been written to assume this TSC speed is fixed over the operation of the machine. As such, a mechanism to accommodate a VM TSC when there is a change in underlying processor speed would be beneficial.